This return exits insertSignatureIntoSelected without setSigningModal(null), so when the SDK's ImageAnnotation/Rect constructors aren't found the signing modal stays open with no feedback — and re-clicking Insert keeps re-failing. Every other exit (!instance at 291, success/catch at 326) clears it. Move the close into a finally.

When createAttachment is absent, attachmentId is null but the code still builds new ImageAnnotation({ imageAttachmentId: null, … }) and creates it — producing a blank/throwing signature rather than failing fast. Bail with a visible message when attachmentId is null instead of flowing it downstream.

The empty dep array makes this cleanup close over the first-render files ([BUILTIN_FILE]), so blob URLs created for later-uploaded files are never revoked on unmount — the exhaustive-deps disable is hiding exactly that stale closure. Track files in a ref and revoke ref.current here, or drop the effect since it currently does nothing useful.

This fallback creates a widget carrying a formFieldName but no backing form field. That orphan is what later breaks renameField (it renames the widget to a name no field has) and leaves a non-functioning field on the page. Consider not creating the widget at all when the FormField constructor is missing, or surfacing the failure.

pageCount is set once here and only viewState.change/zoom.change are subscribed — nothing re-reads instance.totalPageCount after applyOperations add/remove/move. So the "of N" readout, the move-form validation, and the pageCount <= 1 delete-guard all go stale until reload (add pages → count stays old; delete toward 1 → guard checks a stale count). Re-read totalPageCount after each operation.

Filtering by a.constructor?.name === 'InkAnnotation' relies on class names surviving the minified CDN bundle — if they're mangled, "delete drawings on page" silently matches nothing. instanceof window.NutrientViewer.Annotations.InkAnnotation is robust regardless. Same pattern in text/TextToolbar.tsx:206. Worth confirming against the 1.15.0 CDN build.

This rename isn't atomic across the widget↔form-field pair: if the form field can't be resolved (e.g. a widget created via the placeFieldAt fallback with no backing field), only annotation.set('formFieldName', …) runs and the widget desyncs from any field, with no rollback. deleteField (line 236) has the sibling issue — it falls back to annotation.id, deleting the widget and orphaning the FormField.

getFormFields is an always-present core SDK method but is typed optional, so instance.getFormFields?.() short-circuits to null → getFormFieldForAnnotation returns [] → deleteField/renameField silently take the orphan/desync paths. Making it required turns a genuinely-missing API into a caught throw instead of document corruption.

The build script is tsc -b && vite build, and the root tsconfig uses project references, but neither leaf config sets "composite": true. TS build mode errors TS6306 ("Referenced project must have setting composite: true") when references lack it. I couldn't run tsc here — please confirm npm run build passes; if it errors TS6306, add "composite": true to both leaf compilerOptions (allowed alongside noEmit on TS 5.7). Same for tsconfig.node.json.

applyColor/applyFontSize/applyBold/applyItalic repeat an identical guard preamble (instance → instance.annotations?.text → hasSingleTextAnnotationSelected → safeCall); only the final call differs. Extracting a withTextApi(fn) helper collapses the four bodies with no behavior change.

This sdk.unload(container) (and the one in the cleanup return) unloads the shared container node, not the instance this run created. Under React 18 dev StrictMode the effect runs mount→cleanup→mount on the same container, so when this load() resolves late it can tear down the instance the second mount just created — blank viewer in npm run dev. (Production file-switches remount via key, so they're unaffected.) Scope the unload to the instance this effect loaded — resolve into a local and unload that — rather than container.

This isn't accurate: setSelectedAnnotations always takes a NutrientViewer.Immutable.List of annotations/ids (AnnotationSelectionMixin) — there's no plain-array variant “depending on SDK build.” The runtime array fallback is defensive, not a documented contract. Worth correcting since this helper gets copied verbatim.

The payload shapes described here don't match the SDK: selection arrives via annotationSelection.change as an Immutable.List of annotations, and viewState.change carries a ViewState — never { annotation }. The defensive normalization is fine to keep, but the comment describes shapes the SDK doesn't emit and will mislead anyone copying this helper.

deleteField/renameField swallow SDK failures to console.error with no user feedback — the user clicks delete/rename, it silently fails, document unchanged. The rest of the demo surfaces failures (Toolbar's operationError strip, App's window.alert); route these through one of those. (The delete itself is correct — deleting the form field cascades to its widget annotations.)

The updates accumulator is dead: the early return guarantees both .set calls run, so two items are always pushed and updates.length > 0 is never false.

writeJSON is unguarded while readJSON catches. Signature data-URLs are large base64 PNGs, so setItem realistically throws QuotaExceededError (or SecurityError when storage is disabled) — and since saveSignature runs inside a synchronous click handler with no error boundary, the throw escapes uncaught and the insert silently aborts. Wrap it like readJSON and surface a “couldn't save (storage full)” message.

No reader.onerror — if the read fails (unreadable/corrupt file, IO error) onChange never fires, the Insert button stays disabled, and the user gets no feedback (the size-limit branch just above does alert). Add an onerror that clears state and surfaces the failure.

This undo (and the deleteAll handler) catch to console.warn only — the user clicks Undo/Delete, it fails, nothing happens, no indication why. TextToolbar mirrors this. Reuse the operationError pattern from Toolbar so these mutating actions report failure.

This create() failure is console.error-only, but sibling paths in this same function window.alert on failure — so a field dropped off-page (or a license/validation rejection) just silently doesn't appear. Make the feedback consistent.

Is this change (plus the SVG <title> additions under document-authoring/ai-editing/) intentionally part of this PR? It's unrelated to the web-sdk-demo and isn't mentioned in the description — looks like it may have been swept in by a repo-wide format/lint run. Consider splitting it out.